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ELfi2123S7flSUS 
Title: System and method of wireless always-on 
Internet protocol communication 

Inventors: Hao Xue, Dan Wllley, Khaled Islam, & Shahid Chaudry 
Assignee: Research In Motion Limited 
Field of Invention 

The present invention is directed towards die field of point-to-point communication tecliniqaes. In 
particular, Ihe present invention relates to the field of wireless always-on Internet protocol communication. 

Related Art 

A presently known technique of wireless IP conununications that utilizes link control protocols is 
TIA/EIA/IS-835.A (PN-3-4732-RV2-A curr^y being re-baHoted in TR45.e), which is mcotpoiated 
herein by reference. This technique may be an unacceptable solution as it may waste resources of the air 
inter&ce and curtail Ifae mobile station battery life, particularly in out-of-coverage or similar situations 
where it is typical that a link control session does not remain operable. 

RFC 1661 specifies a link control protocol, point-to-point protocol ^PP), which is incorporated 
herein by reference. Certain aspects of PPP, such as LCP Echo-Requests and Echo-Reply, may not be 
optimized for wireless communication, as many data fields in PPP, when sent over the air, are un- 
inteipreted and tiberefore may waste resources of tiie air inter&ce and curtail the mobile station battery life. 

There remains a need for a robust technique of wireless always-on IP communication that remains 
operable in an out-of-coverage or similar situation. 

Summary of Invention 

It is an object of the present invention to obviate or mitigate at least one disadvantage of previous 
wireless IP techniques. It is a further object of the present invention to provide a system and method of 
wireless always-on Internet protocol communication that is robust against out-of-coverage and like 
situations, and \^ch systematically provides reliable communications. 



According to a first aspect of the present invention, a wireless system having always-on 
components is provided. The always-on components enable always-on wireless Internet Protocol (IP) 
conmmnications. 

According to a second aspect of the present invention, an always-on method carried out in various 
always-on components is provided. The always-on method enables always-on wireless Intemet Protocol 
(IP) communications at tiiose components that cany out the method. 

Ober aspects and features of the present invention will become apparent to those ordinarily skilled 
in tilie art i:^on review of the following description of specific embodiments of the invention in conjunction 
with the accompanying FIGS. . 

Brief description of the Drawing 

Embodiments of the present invention will now be described, by way of example only, with 
reference to the attached FIGS. , wherein: 

FIG. 1 shows one embodiment of a system for wireless always-on IP communication; 

FIG. 2 shows Ihe protocol stacks at various con^nents of the system of HG. 1; 

FIG. 3 shows details of one embodiment of the always-on MS of FIGS. 1 and 2; 

FIG. 4 shows details of one embodiment of die always-on PDSN of FIGS. 1 and 2; 

FIG. 5 ^ows one embodiment of a method of imtiating PPP at an always-on MS; 

FIG. 6 shows a first embodiment of a method of maintaining synchronization of PPP in an always- 
on MS; 

FIG. 7 shows a second embodiment of a method of maintaining synchronization of PPP in an 
always-on MS.; and 

FIG. 8 shows one embodiment of method in a PDSN for maintaining synchronization of PPP for 
always-on MSs. 

Detailed Description 

According to a first aspect of the present invention, a wireless system having always-on 
components is provided Ihe always-on conqponents enable always-on wireless Intemet Protocol (IP) 
conununications. ' 

Referring to FIG. 1, FIG. 1 shows one embodiment of a system for wireless always-on IP 
commumcation, which will be described presently. An always-on mobile station (MS) 10 communicates 
over an Int^et Protocol (IP) Network 30 with an end host 40 via at least one always-on access provider 
netwoik (APN) cooperating with back-end infi:astmcture. Always-on MS 10 conmuuucates with a first 
always-on visitmg APN 20V, and then is handed-off to a second always-on serving APN 20S. The always- 
on serving APN 20S communicates to back-end infiastructure including a home APN 60, a home IP 
network 70, and a broker netwozk 80. Alternatively, the always-on MS 10 could communicate with back- 
end infrastmcture directly via always-on serving APN 20S. 



Bodi the always-on serving and visiting APNs 20S,20V include known conqponents such as a 
ladio network (RN) 22S,22V. As illustrated in the case of the serving APN 20S. known components 
include mobile switching center (MSG) 23S which connects the source RN 22S widi a home location 
register (HLR) 62 at die home APN 60 via signaling system 7 (SS7) network 50. Also known is serving 
remote audientication dial in service (RADIUS) 24S that communicates with corresponding RADIUS 
components home RADIUS 74 and broker RADIUS 84 in die home IP network 70 and broker networic 80 
respectively. 

Also known are the home IP network 70 and broker network 80, which are typically accessible 
over the same IP network 30 on which resides the end host 40. IP netwodc can be any network, such as die 
Internet or a private IP network or an intranet 

Further details on the operation of these known components can be found in TlA/EIA/IS-2000-1, 
IWEIAaS-2000-2, TIAmiA/IS-2000-3, TlA/EIA/IS-2000-4, TIA/EIA/IS-2000-5, 3GPP2 C.SOOOl, 
3GPP2 C.S0002, 3GPP2 C.S0003, 3GPP2 C.S0004, 3GPP2 CS0005, TIA>TEIA/IS-707. 3GPP2 C.S0017, 
and their revisions, which are incorporated herein by reference. 

In addition to known components in the always-on APN 20S, an always-on serving packet data 
serving node (PDSN) 25S is also ^own. The always-on serving PDSN 25S co-operates widi the always- 
on MS 10 via an always-on target PDSN 25V at the always-on visiting APN 20V. 

In alternate embodmients of the first aspect, APNs 20S and 20V need not bodi be of the always-on 
variety, but rather it is sufficient that at least one APN which communicates with always-on MS 10 be of an 
always-on type, die always-on MS and always-on APN both provided in accordance with the present 
invention. Furdier details of the always-on MS 10 will be described witih reference to FIGS- 2 and 3 below, 
whereas further details of always-on APN and always-on PDSN wiU be described with refer^ice to FIGS. 2 
and 4 below. 

Turning now to FIG. 2, FIG. 2 shows the protocol stacks at various conqponents of the system of 
FIG. 1, which will be desoibed presently. Four protocol stacks 110,122,125 and 140 are illustrated, each 
corresponding respectively to always-on MS 10, RN 22, always-on PDSN 25 and end host 40 of FIG, 1 
respectively. Stacks 110 and 125 inchide always-on PPP layers 1 15 and 130 respectively. Always-on PPP 
layers 1 1 5 and 130 co-operate to ensure tiiat the PPP session which enables IP communication between the 
MS and die end host is maintained despite out-of-coverage or similar situations at die MS, such as for 
example due to the wireless air Imk between the MS and die RN. Further details of the operation of die 
always-on PPP layer 115 at the always-on MS will be described in reference to Fig. 3, whereas fiirdier 
details of the operation of die always-on PPP layer 135 at the always-on PDSN will be described in 
reference to Fig. 4 

Referring now to FIG. 3, FIG. 3 shows details of one embodiment of die always-on MS of FIGS. 1 
and 2. The always-on MS 310 inchides a processor 320, a transceiver 322 as well as an always-on MS 
module 315 that keeps track of and operates based upon the value of a PPP inactivity timer estimate 330. 



Other modules 340 include what is normally required to operate a MS, such as a screen and keyboard 
and/or speaker and microphone, etc. 

Operationally, when tiie transceiver 322 of always-on MS 310 receives an always-on echo-request 
350, the transceiver passes the request onto the processor 320, which then sends the data 355 to the always* 
on MS module. The data portion 355 includes a PPP mactivity timer value that is used by the always-on 
MS module 315 to set tiie PPP inactivity timer estimate. TTxe value of the PPP inactivity timer estimate 330 
in turn affects ftie operation of the always-on MS module 315, particularly in out-of-coverage situations 
that can be signaled to the always-on MS module by the transceiver 322, processor 320, and other modules 
340. To maintain an always-on connection, the always-on module can, eidier exclusively or in 
combination, receive always-on echo-request 350, send echo-reply 360, send echo-request 370, receive 
echo-reply 380 or initiate PPP-session 390. 

FIG. 4 shows details of one embodiment of the always-on PDSN of FIGS. 1 and 2. The always-on 
PDSN 425 includes a processor 420, a transceiver 422 as well as an always-on PDSN module 415 that 
keeps track of and operates based iq^on the value of a PPP inactivity timer 430. Other modules 440 include 
what is normally required to operate a PDSN, such as additional transceivers for various networks, etc. 

Operationally, when the tcansceiver 422 and processor 420 detect PPP activity with an always-on 
MS, the always-on PDSN module 415 is notified of the activity and as such resets the PPP inactivity timer 
430. At least once after a PPP session has been initiated for a MS, the value of the PPP inactivity timer 430 
is sent to the always-on MS via an always-on echo-request 450 by the always-on PDSN module 415. The 
always-on echo request 450 includes the value of the PPP inactivity timer m the data field - which is 
normally un-inteipreted according to RFC 1661. Otiier techniques are envisaged to send this value to the 
MS, what is desirable is that the MS has an accurate estimate of the PPP inactivity timer. Urns, whenever 
the maximum value of the timer changes, it is desirable to send the new value to the MS« PPP activity 
which causes the always-on PDSN module 415 to reset the PPP inactivity timer include either exclusively 
or in combination sending an always-on echo-request 450, receiving an echo reply 460, receiving an echo- 
request 470, sending an echo reply 480 and receiving an initiate PPP-session 490. 

Having described the first aspect of the present invention, according to a second aspect of tiie 
present invention, an always-on method carried out in various always-on corrq>onents is provided. The 
always-on method enables always-on wireless Internet Protocol (IP) communications at those con^onents 
that canyout the method. 

Referring to FIG. 5, FIG. 5 shows a method of initiating PPP at an always-on MS. Referring to 
FIG. 5, Step 500 shows the start; this step would happen, for exanq>le, when an always-on MS is powered 
on. In step 505 the MS initiates PPP. For example, the MS could initiate a call (for further details, the 
reader is referred to TIA/EIA/IS-2000-1, TIA/EIA/IS-2000-2, TIA/EIA/IS-2000-3, TIAyEIA/IS-2000-4, 
TIA/EIA/IS-2000-5 which have been incorporated herein by reference) using a packet data service option 
such as Sendee option 33 (for iur&er details, the reader is referred to TDWEIA/IS-TO? which has 
incorporated herein by reference). The PDSN then initiates tiie PPP session to the MS. In Step 510, tiie 



MS enters the IPCP Opened state. In step 515, the MS checks to see if it has received a message with a 
data field. Preferably liie message is an LCP Echo-Request message sent by the PDSN. The data field 
could be received in other ways such as via an A-interface message in a new version of the A-interface sent 
from the PDSN to the RN and then to the MS via a message defined in a new version of IS-707. Using the 
LCP Echo-Request to carry the data field is prefenred because it only requires a change to IS-835 and not to 
IS-707 and the A-interface. When the MS checks to see if it receives tiie message, it could allow a certain 
time period within which it would expect die message - 5 seconds, for exanqjle. If a message with die data 
field is received within diis time period, processing continues in FIG. 6. If a message widi the data field is 
not received within this time period, then processing continues in FIG. 7. The data field sent to the MS 
preferably contains the value of the PPP inactivity timer. Other information could also be sent via the data 
field. For example, the information on voice call handling 

Turning to FIG, 6, FIG. 6 shows a method of maintaining synchroni2ation of PPP in an always-on 
MS. The PPP inactivity timer is reset at step 600. For example, if the MS bad received a value of 60 
seconds for the PPP inactivity timer, it could set a timer to 60 and count down once per second such that it 
would expire if it reached zero. Processing continues at decision step 605. If diere is PPP activity, then 
processing continues at step 600. If there is no PPP activity, then processing continues at step 610. PPP 
activity could be determined by receiving a PPP packet from the PDSN or by sending to the PDSN a PPP 
packet for which there has been acknowledgement. At decision step 610, die MS checks to see if there is a 
condition that makes it unreachable. Such a condition could be for example, a loss of die paging channel 
(see C.S0005-0-2 which has been incorporated herein by reference.) Another such condition could be 
when making a voice telephone call using a service option such as EVRC when the air interface does not 
support concurrent services. If there is no condition diat makes die MS unreachable, processii:^ continues 
at step 605. Odierwise, if there is a condition diat makes die MS unreachable, processing continues at step 
615. At decision step 615, the MS checks to see if it is again reachable. An exarnple of die MS becoming 
reachable again would be if the MS reacquired the Pagiag Channel after a loss of the paging channel. 
Another example would be if the MS ended a voice telephone using a service option such as EVRC. If die 
result of decision step 615 is that the MS is not yet reachable, processing remains at decision step 615. If 
die result of decision step 615 is that the MS is reachable again, dien processing continues at decision step 
620. At decision step 620, die MS checks to see if the PPP inactivity timer has cxpmdL If die check 
determines diat die PPP inactivity timer has not expired, then processing continues at step 605. If the check 
determines that the PPP inactivity timer has expired, the processing continues at step 625. At step 625, die 
MS sends an LCP Echo-Request message to the PDSN. Processing continues at step 630. After the MS 
receives an LCP Echo-Reply fix>m the PDNS in step 630, processing continues at step 600. 

Tuming now to FIG. 7, FIG. 7 shows a method of maintaining synchronization of PPP in an 
always-on MS. Processing begins at decision step 700. At decision step 700, the MS checks to see if diere 
is a condition diat makes it unreachable. Sudi a condition could be for example, a loss of the paging 
channel (see C.S0005-0-2.) Another such condition could be when making a voice telephone call using a 
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service option such as EVRC when ihe air interface does not support concurrent services. If there is no 
condition diat makes the MS unreachable, processing continues at step 700. Otherwise, if there is a 
condition that makes ftie MS unreachable, processing continues at step 705. At decision step 705, the MS 
checks to see if it is again reachable. An example of the MS becoming reachable again would be ifihe MS 
reacquired the Paging Channel after a loss of the paging channel. Another example would be if the MS 
ended a voice telephone using a service option such as EVRC. If the result of decision step 705 is diat the 
MS is not yet reachable, processing remains at decision step 705. If the result of decision step 705 is that 
the MS is reachable again, then processing continues at decision step 710. At step 7 10 the MS initiates PFP 
as in FIG. 5. 

Referring now to FIG. 8, FIG. 8 shows an embodiment of method in a PDSN for maintaining 
synchronization of PPP for always-on MSs. la step 800 the PDSN initiates PPP. Processing then continues 
at step 805 where the PDSN enters the IPCP opened state (Internet Protocol Control Protocol opened state 
as described in RFC 1332 which hereby incorporated herein by reference), processing then continues at 
step 810 where the PDSN sends an LCP Echo-Request message including a Data field of non-zero length. 
The Data field contains die value of tfie PPP inactivity timsr. Other information could be included m tins 
Data field as welL The data field could be sent via other messages, but it is preferred to send it in an LCP 
Echo-Request After sending a message with the Data field, processing continues at step 815. At 815 the 
PDSN starts (or resets) the PPP inactivity timer. For example, if the value of 60 seconds is used for the 
PPP inactivity timer, the PDSN could set a timer to 60 and coimt down once per second such that it would 
expire if it reached zero. After the PDSN starts the PPP inactivity timer processing continues at decision 
step 820. If there is PPP activity, then processing continues at step 815. If there is no PPP activity, then 
processing continues at step 825. PPP activity could be determined by receiving a PPP packet from the MS 
or by sending to tiie MS a PPP packet for which there has been acknowledgement At decision step 825, 
the PDSN checks to see if Ihe PPP inactivity timer has expired. If the check determines that tiie PPP 
inactivity timer has not expired, then processing continues at step 820. If tiie check determines that the PPP 
inactivity timer has expired, tiie processing continues at step 830. At step 830, the PDSN sends an LCP 
Bcho-Request message to the MS. Processing continues at step 835. At step 835 the PDSN starts an Echo- 
Reply timer and also decrements the Echo-Request-Retries coimter by one. Processing then continues at 
decision step 840. At decision step 840, the PDSN checks whether it has received an LCP Echo-Reply 
message, and LCP Echo-Request message, or any otiier PPP message firom tiie MS. It should be noted that 
this differs fiom previous versions of the standard - in previous versions of the standard tiie PDSN only 
checked for an LCP Echo-Reply. Checking for tiie LCP Echo-Request allows tiie PDSN to take advantage 
of die Echo-Request being sent by the MS as shown in step 625 of FIG. 6. When the PDSN receives this 
message tiie result will be that the PPP inactivity timer is reset and the likelihood that PPP is released by 
the PDSN (causing an out-of-sync condition with the MS) is reduced. Furthermore, by checking for other 
PPP messages the PDSN would be able to reset the PPP inactivity timer even if neither an LCP Echo- 
Request nor an LCP Echo-Response is sent by the MS but if the MS sent any other PPP packet, thus further 



reducing the probability of an out-of-sync condition widi die MS. If die result of decision step 840 is ttiat 
one of the above described messages was received, die processing continues at step 845. If die result of 
decision step 840 is diat none of the above described messages was received, then processing continues at 
decision step 850. At step 845 the PDSN stops die Echo-Reply timer and dien processing continues at step 
815. At decision step 850, the PDSN checks to see if the Echo-Reply timer expired. If die Echo-Reply 
timer has not e^ired, processing continues at decision stq> 840. If the Echo-Reply timer has expired, 
processing continues at decision step 855. At decision step 855 the PDSN checks to see if the Edio- 
Request-Retries counter is greater dian zero. If die counter is greater dian zero, processing continues at 
step 830. If the counter is not greater than zero, dien processing ends at step 860 where the PDSN releases 
PPP. 

Although not expressly shown in the drawings, an alternate always-on APN including an always- 
on RN that cooperates with the always-on PDSN and always-on MS to treat voice calls as PPP activity is 
also envisaged. The always-on PDSN determines from the always-on RN that the always-on MS is 
currently in a voice call, and therefore that the MS is unreachable for the purposes of PPP communication. 
The alway&-on PDSN treats die always-on MS as if it were active for the purposes of PPP. A 
corresponding alternate embodiment of die always-on MS is also envisaged adapted to this functionality, 
the MS also treats die voice call as PPP activity. 

Additional details regarding the embodiments of the present invention may be found in the 
appendices attached herewith and included herein. 

The above-described embodiments of die present invention are intended to be examples only. 
Alterations, modifications and variations may be effected to the particular embodiments by diose of skill in 
die art without departing from the scope of the invention. 



ABSTRACT 

A system and method of wireless always-oo bit^et protocol communication is disclosed herein. The 
disclosed method and system prevent the loss of connectivity to an end-host resulting from out-of-coverage 
situations and the like at a mobile station (MS). The disclosed method and system prevent wasted air- 
interface resources and improve battery life at a MS. 
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ABSTRACTT: 

Proposes resolution to RIM^s PN-3-4732-RV2-A ballot comment #1 regarding 
Battery Life and Reachability/Capacity issues. 



RECOMMENDATION: 

Discuss and adopt. 
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incorporate text or other copyrightable material contamed in this contribution and any modifications diereof 
in the creation of a TIA Publication; to copyright and sell in TIA's name any TIA Publication even though 
it may include all or portions of this contribution; and at TIA's sole discretion to permit odiers to reproduce 
in whole or in part such contribution or the resulting TIA Publication. This contributor will also be willing 
to grant licenses under such copyrigjits to third parties on reasonable, non-discriminatory terms and 
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1 l^Introdaction 

2 

3 The reballot text for TIA/EIAyiS-835-B has problems that result in boA wasted air intecfoce capacity and 

4 poor battery life for always-on devices. 

5 Currently the behavior of tite PDSN creates situations where the MS must initiate a PPP session in order to 

6 guarantee that there be no dismption in service. For exan^le the below figure depicts a Simple IP case 

7 where (he MS has gone out of coverage for a short time and then comes back in coverage. During the time 

8 the MS is out of coverage, the PDSN could have ended the PPP session and tfie MS would have no way of 

9 knowing. In order to guarantee service, the MS must initiate a PPP session, wasting both air interface 
10 capacity and battery life. 

good co^U ^ ^ ®^ 



Forward link status 
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MS 
ii^atds 
PPP 

11 
12 

13 2. Recommendation 

14 In order to resolve the issue, we recommend the following: 

15 1 . Support for alway s-on devices must be mandatory for tiie PDSN. 

16 2. For the case of Simple IP, die MS must be informed of the value of flie PPP inactivity timer. 

17 3, The PDSN must never tear down PPP before the expiration of the PPP inactivity timer is such a 

18 way as to leave tiie MS unreachable. This and the value of the PPP inactivity timer will allow the 

19 MS to stop reinitiating PPP after every temporary loss of coverage. 

20 4, In order to preserve battery life for the always-on device and to avoid wasting air inter&ce 

21 capacity, there must be a mmimum allowed PPP inactivity timer for the always-on device. We 

22 recommend a value of two hours. 

23 5. In the Shx^le IP case, when ^e MS is out of coverage when the PPP mactivity timer expires, the 

24 MS should be allowed to send an Echo Request message when it is back in cov«age. 

25 - 

26 The below figure demonstrates the benefits of the recommended changes. The figure depicts a Simple IP 

27 case where the MS goes in and out of coverage three times. The PDSN is configured to retry die Echo 

28 Request one time. After tfie first time the MS goes out of coverage, the PPP inactivity time has not expired 

29 and since the MS knows die time it will expire, it need not send a message, thus saving both air inter&ce 

30 capacity and battery life. During the second time die MS is out of coverage, die PDSN inactivi^ timer 

3 1 expires. The PDSN sends the Echo request, but since the MS is out of coverage, it does not receive die 

32 response. When the MS is back in coverage, it sends an Echo request, and die PPP inactivity timer is reset 

33 The Echo Reply Tfaneout timer is set such that it would have gone off during ttie third instance where the 

34 MS is out of coverage. If die MS had not sent die echo request, PPP would have been torn down during 

35 diis third instance. 
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Echo request 
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no 

1 response 

2 3. Proposed Changes 
3 

4 

5 [...] 

6 5 Simple IP Operation 

7 I...] 

8 5.2 PDSN Requirements 

9 [...] 

10 5^.1 PPP Session 

11 [...] 

12 5 .2 Termination 

13 I..J 

14 The PDSN may receive the Always On attribute with value '1' from the HAAA in order to activate 

15 Always On sen/Ice for a user. Upon receivma the Always On attribute with value '1' from the 

16 HAAA ,To implGmont Always On oorvico for - a uoor - t he PDSN shall utilize the expiration of the 

17 PPP inactivity timer and the procedures described in Section 5.2.1.7 to determine if the PPP 

18 session should be closed. After receivino the Alwavs On attribute with value *1' from the HAAA. 

19 the PDSN shall not set the PPP inactivih/ timer to a v alue shorter than two hours. 

20 (...] 

21 5.2. 1 .7 PPP Link Status Determination 

22 If the PDSN supports Alwoys On son/ico, thoi he PDSN shall support the following configurable 

23 timer and counter 

24 • Echo-Reply-Timeout timer 

25 • Echo-Request-Retries counter 

26 Upon entering the IPCP Opened state on a PPP session configured for Always On Service, the 

27 PDSN shall send over the main service instance an LCP Echo-Request messaoe fRFC 1661 j 

28 with the Data field of the Echo-Request packet set to a two-byte field representing the value of 

29 the PPP inactivltv timer in seconds, and shall s tart the PPP Inactivity timer for the PPP session in 

30 question. Upon expiration of the PPP inactivity timer, the PDSN shall send an LCP Echo- 

31 Request message [RFC 1661] over the main service Instance, and start the Echo-Reply-Timeout 

32 timer for the PPP session In question, it shall also initialize the Echo-Request-Retries counter to 

33 a configurable integer value. 

34 Upon receipt of an LCP Echo-Reply messag e, an LCP Echo-Reauest message [RFC 1 6611. or 

35 anv other PPP oacket for the PPP session in question, the PDSN shall stop the Echo-Reply- 

36 Timeout timer, reset the Echo-Request-Retries counter, and start the PPP inactivity timer. 

37 The PDSN shall adhere to RFC 1661 section 5.8 "Echo-Request and Echo-Reolv" with regards to 

38 LCP Echo-Request messaoe processing. 

39 Upon expiration of the Echo-Reply-Timeout timer when the Echo-Request-Retries counter value 

40 is greater than zero, the PDSN shall send an LCP Echo-Request message, decrement the Echo- 

41 Request-Retries counter by one, and start the Echo-Reply-Timeout timer. 



3 



1 Upon expiration of the Echo-Reply-Timeout timer when the Echo-Request-Retries counter value 

2 is equal to zero, the PDSN shall release the PPP session. 
3 

4 [...] 

5 5.4 MS Requirements 

6 [...1 

7 5.4.1 PPP Session 

8 [...] 

9 5.4. 1 .7 PPP Link Status Determination 

10 To support Always On service, the MS shall adhere to RFC 1661 section 5.8 "Echo-Request and 

1 1 Echo-Reply" with regards to LCP Echo-Request message processing. 

12 If the MS supports Always On service and it receives an L CP Echo-Reauest message with the 

13 Data field set to a two-bvte nonzero value, it shall maintain an MS PPP inactivity timer based 

14 upon this value. Upon expiration of the MS PPP inactivitv tim er the MS shall send over the main 

15 service instance an LCP Echo-Reauest messao e ^RFC 16611. 

16 [..J 
17 

18 

19 13 Radio Network Requirements 



20 13.1 General 

21 The PDSN interfaces to the Radio Network only through the R-P interface and there are no RN 

22 dependent signaling messages transmitted to the PDSN. However, there are some general 

23 requirements placed on the RN: 

24 • Each RN is connected to at least one PDSN. 

25 • The RN relays PPP frames between the MS and PDSN. 

26 • The RN establishes an R-P connection for each MS initiated packet data service 

27 instance. If the MS Initiates multiple service Instances, each R-P connection is directed to the 

28 same PDSN. 

29 • The RN terminates the R-P connection if the MS terminates the packet data session-ef 

30 If tho RN dotonninoG that tho MS io no longer roaohoble . 

31 m The RN shall not terminate the R-P connection if it detenmines th at the MS is not 

32 reachabie fin such a situation, the MS mav be temoorar ilv out-of-coveraae.) 

33 • For some service options, the RN may buffer user data from the PDSN when radio 

34 resources are not In place or insufficient to supporth the flow of data. 

35 • The RN passes octets between the MS and PDSN without any framing conversion. 

36 [...1 
37 

38 
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ABSTRACT: 

Proposes removing a redundant requirement. 



RECOMMENDATION: 

Discuss and adopt. 
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I 1. Introduction 

2 

3 The second resetting of the Echo-Request Retries counter is redundant; it will be reset 

4 when the PPP inactivity timer expires.. 
5 

6 2. Proposed Changes 

7 

8 

9 [...] 

10 5 Simple IP Operation 

II I-l 

12 BJ2 PDSN Requirements 

13 [..J 

14 5,2.1 PPP Session 

15 [...1 

16 5.2.1.7 PPP Link Status Determination 

17 If the PDSN supports Always On service, the PDSN shall support the following configurable timer 

18 and counter. 

19 • Echo-Reply-Timeout timer 

20 • Echo-Request*Retr!es counter 

21 Upon entering the IPCP Opened state on a PPP session configured for Always On Service, the 

22 PDSN shall start the PPP inacUvity timer for the PPP session in question. Upon expiration of the 

23 PPP inactivity timer, the PDSN shall send an LCP Echo-Request message [RFC 1661] over the 

24 main service instance, and start the Echo-Reply-Timeout timer for the PPP session in question. It 

25 shall also Initialize the Echo-Request-Retries counter to a configurable integer value. 

26 Upon receipt of an LCP Echo-Reply message [RFC 1661] for the PPP session in question, the 

27 PDSN shall stop the Echo-Reply-Timeout time r, roootthq Echo Roqucot Rotrioo counter,, and 

28 start the PPP inactivity timer. 

29 Upon expiration of the Echo-Reply-Timeout timer when the Echo-Request-Retries counter value 

30 is greater than zero, the PDSN shall send an LCP Echo-Request message, decrement the Echo- 

31 Request-Retries counter by one, and start the Echo-Reply-Timeout timer. 

32 Upon expiration of the Echo-Reply-Timeout timer when the Echo-Request-Retries counter value 

33 is equal to zero, the PDSN shall release the PPP session. 
34 
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